A mobile packet flow is a packet flow which during an ongoing communication session changes its way or route through the network, for example in consequence of a roaming mobile terminal or in consequence of a roaming mobile network.
Middleboxes and midcom agents (MIDdlebox COMmunication agents) are specified in [1] and [2]. Basically, middleboxes are intermediate devices in the Internet that require application intelligence for their operation.
Middleboxes may implement a large variety of network nodes, such as firewalls, network address translators (NAT), access routers and many other types of nodes. Middleboxes typically have corresponding application intelligence embedded within the device for their operation.
Middleboxes may enforce application specific policy based functions such as quality of service (QoS) control, resource management, packet filtering, virtual private network (VPN) tunnelling, intrusion detection, security and so forth.
FIG. 1 illustrates the use of middleboxes and according to [1], [2]. A user A of a terminal equipment, TE, 1 communicates with a session controller 2 in order to set up communication, for example a video call on the cellular network, with user B that has a terminal equipment, 3. User A sends a communication request to the session controller which communicates with the parties in order to set the conditions for the requested session, such as communication type, bandwidth and costs. This signalling is termed session signalling and takes place on a session layer. An example of a session layer signalling protocol is the Session Initiation Protocol (SIP). IP telephony is one example of a service supported by this protocol.
In the set up phase the terminal equipments also need to signal their individual needs, such as required bandwidth, to the nodes along the path the requested communication shall follow. This signalling is referred to as IP control signalling and takes place at an IP control plane 4 which in its turn takes place on the IP layer 5. The session controller reserves the resources required for a specific session.
An example of an IP control signalling protocol used on the IP control plane is the Resource Reservation Setup Protocol (RSVP) for resource reservation on the Internet. It is thus clear that signalling at both the session layer and the IP layer is needed in order to set up a session with reserved resources. As is well known the TCP/IP protocol suite has two separate signalling layers, one at the session layer, and one at the IP layer.
When the set up phase has finished user A is allowed to start the communication. Communication starts and the terminal equipments exchange packets. The packets from A to B and from B to A contain user data and together form a user data flow which follows a user data path on a user data plane 6 on the IP layer 5. In FIG. 1 the IP layer 5 is illustrated to comprises the IP control plane 4 as well as the user data plane 6. The user data path passes many middleboxes and nodes NO in many non shown networks along their way from source to destination. In FIG. 1 two middleboxes 7 and 8 and one node NO along this path are shown. Control functions for the user data flow are distributed among the middleboxes.
In FIG. 1 no midcom agent is shown. However, one can imagine that there is a midcom agent distributed among the middleboxes. Each middlebox would thus contain a part of a midcom agent. The above mentioned IP control signalling path between the terminal equipments and nodes and middleboxes on the IP control layer is illustrated by the thin double headed arrow 9 and the user data flow follows a user data path illustrated with the bold double headed arrow 10. In prior art, the user data plane and IP control plane are both on the IP layer 5 and the IP control signalling path 9 and user data path 10 are transported along a common channel 11. The session signalling is shown at double headed arrow 12 and may follow a different path than the common channel. The session controller must determine which routers and middleboxes the user data flow traverses so that it can direct control messages, related to the user data flow, to these nodes.
There is also a need to coordinate the resource utilization and the configuration of firewalls and other types of middleboxes. For coordination purposes, the use of a centralized control entity is favourable. The definition of such an entity, called a Midcom Agent, is addressed by the IETF Midcom working group [midcom]. According to a proposal from the working group the IP layer is divided into an IP control plane and a user plane.
A main drawback with prior art relates to control of moving user data flows. When the route of a flow is changed the combined user packet flow and IP layer signalling flow will encounter routers, middleboxes and other network nodes that have no knowledge of the flow and therefore don't know how to handle the flow, where it should be routed, which resources it requires, questions relating to authentication and accounting and many other considerations.
In accordance with the prior art this dilemma is solved in the following manner: a middlebox, sitting or located at the edge of a network and therefore called an edge middlebox, receives an unknown flow, starts an admission control of the flow in order to determine if the unknown flow should be granted access to the network. Via IP control signalling the edge middlebox receives knowledge of the flow, the bandwidth the flow requires and the identity of the entity responsible for the unknown flow. Having this knowledge the edge middlebox signals a database in order to verify that the entity responsible for the flow, usually a subscriber, is a trusted entity and has a subscription that encompasses the used bandwidth. This part of the admission control is termed policy control. Another part of the admission control is to check that the network has resources available for the unknown flow. This check is typically done using hop-by-hop signalling from one node to another along the path from source to destination in order to verify that the links have sufficient bandwidth free to accommodate the bandwidth of the unknown flow.
A problem with the existing proposal from the Midcom working group is that signalling messages for a specific session do not necessarily traverse the same routers and middleboxes as the user data flow of the session. The IP control plane must therefore determine which routers and middleboxes a specific user flow traverses so that it can direct control messages related to this flow to these nodes. The existing solutions in prior art handle policy control, or control of firewalls and address translators, but cannot provide communication for general purpose connection control between midcom agents and middleboxes.
In multi-access scenarios with multiple radio hops and requirements on session continuity in complex handover situations, the technology described herein proposes the use of an IP layer signalling protocol to transfer control messages to the middleboxes in order to ascertain that a user data IP flow is processed correctly.
The use of two separate signalling protocols to set up a session introduces unnecessary complexity and is a waste of bandwidth, especially over radio interfaces.
Processing of signalling information is not an instant process but takes a certain time at each middlebox. Signalling is therefore a slow serial process that jumps from one middlebox to another. The signalling delay taking place at one middlebox will add to the signalling delay at the next middlebox. In this manner delays are added and control signalling across the network is slow, in particular if the number of jumps is large.
Accordingly control of moving packet flows is a slow process. During the admission control process storage of the unknown flow at the edge middlebox is required so as to avoid loss of packets. This requires storage resources.
Another main drawback with the prior art relates to upgrading of the middleboxes. All of the middleboxes in a network need to be upgraded separately. Upgrading needs for example be made in case the existing control software of the middleboxes should be replaced with an evolved version of the control software.
Still another drawback with the prior art relates to feature interaction in middleboxes. Feature interaction appears when a middlebox has received an order to execute some predefined first processes and later on receives a new order to perform some other second processes. When the second processes execute they may interact in an undesirable manner with the first processes. The result is that the operation of the middlebox will be unpredictable. Different middleboxes contain different functionalities and the flows will thus be handled differently in different middleboxes.